u-trip - admin definitiefase
Home

u-trip - admin definitiefase

u-trip - admin definitiefase

In deze fase bepalen we de eisen en wensen die aan het projectresultaat gesteld worden zo nauwkeurig en compleet mogelijk. Het gaat er vooral om de verwachtingen van de betrokken partijen over wat het projectresultaat moet zijn duidelijk op papier te krijgen.

Context

De website en de admin-app moeten het mogelijk maken uitstappen te organiseren voor bijvoorbeeld een school of een hotel. De deelnemers volgen een traject en kunnen feedback geven. Achteraf kan de leraar of begeleider de feedback per deelnemer bekijken en op zijn beurt feedback opstellen. Daarnaast heeft de leraar de mogelijkheid om een ranglijst van de meest enthousiaste deelnemer op stellen.

Functionele eisen

Admin

  1. Er moet een aparte webapplicatie gemaakt worden om de database te beheren.
  2. Voor elke entiteit moet er een tegel op de index pagina staan waarmee je de entiteit kan beheren (CRUD)
    1. mmt - ERD
    2. u-trip - logisch model
    3. Voor de structuur en lay-out baseer je je op:
      1. Fric-frac Opmaak met CSS
      2. Fric-frac Postioneren met CSS
      3. Fric-frac Wireframes
  3. Mogelijke rollen:
    1. administrator (ADMIN)
    2. direct verantwoordelijke (DIRECTOR)
    3. begeleider (SUPERVISOR): alles wat deelnemer kan + bezienswaardigheid toevoegen
    4. deelnemer (MEMBER): alles wat gast kan + foto's opsturen
    5. gast (GUEST): kan commentaar opsturen, mits het meesturen van e-mail adres
  4. Alleen de ADMIN en DIRECTOR hebbentoegang tot deze website.
  5. De ADMIN en DIRECTOR moeten over een UI beschikken waarmee hij tours kan uitstippelen.
  6. De Admin app wordt gemaakt in PHP met Threepenny MVC, dus geen MSSQL!
  7. De gebruikersapp wordt gemaakt zoals we Fric-frac hebben gemaakt in Programmeren 3:
    1. je schrijft dus zelf de HTML ;
    2. en je gebruikt de CSS van dit project.;
    3. dus geen React en ook geen Bootstrap!

Niet-functionele eisen

  1. Supportability
    1. Documentatie (Word of OneNote) tijdens ontwikkeling
    2. PDF einddocumentatie

Operationele eisen

Operationele eisen gaan over de eisen aan het gebruik van het projectresultaat.

  1. De slordigheid bij het uitvoeren van de procedures moet met 90% afnemen.
  2. Door een logboek bij te houden is mogelijk om achteraf een analyse te maken van wat er is mis gelopen.

Ontwerpbeperkingen

Ontwerpbeperkingen zijn eisen die te maken hebben met de realisatie van het project zelf.

  1. Een native app is uitgelsloten omdat de app op alle mobiele platformen moet draaien, daarom wordt er gekozen voor React-native.
  2. Voor de oefening voor deze module beperken we ons tot:
    1. gast
    2. deelnemer
    3. geen loggegevens
  3. Aangezien we niet veel tijd hebben, gaan we niet beginnen met het authenticatie gedeelte te implementeren. Dat doen we alleen als er tijd genoeg is.
  4. De opdrachtgever wil zo snel mogelijk een resultaat. Dat wil zeggen dat we volgens de agile methode gaan werken:
    1. Snel schakelen
      Tijdens elke sprint wordt een functionaliteit gerealiseerd. Gedurende het project kan blijken dat een bepaalde functionaliteit aangepast, toegevoegd of weggelaten moet worden. Op basis van voortschrijdend inzicht kan op tijd worden bijgestuurd en wordt voorkomen dat naderhand grote aanpassingen gedaan moeten worden.
    2. Elke twee weken een werkend product
      Met elke sprint wordt een werkend product opgeleverd, dat direct getest en gebruikt kan worden. Als klant kunt u het systeem geleidelijk in productie nemen. U hoeft dus niet te wachten tot de oplevering van het gehele project om te profiteren van uw nieuwe CRM systeem.
    3. Optimale ROI (return in investment)
      De genoemde voordelen van een agile (scrum) aanpak, zorgen ervoor dat de ROI (return in investment) van app implementatie wordt gemaximaliseerd. Door een optimale controle over het project en de mogelijkheid om snel in te spelen op veranderende prioriteiten, omstandigheden en behoeften, zijn we verzekerd van een werkend systeem te produceren binnen de tijdslimiet van deze module.
    4. Nog eens kort samengevat: basis van Agile en ROI:
      1. Agile is concerned with getting the fastest ROI
      2. Continuous iterative development
      3. Progressive incremental delivery
        1. to provide Business Benefit throughout the development
      4. Driven by costs and timescales
        1. Functionality is removed or deferred
      5. Assumes not everything is known
        1. Anticipates Change will happen
      6. Fast feedback supports continuous improvement
      7. Collaborative working between
        1. between Client and Supplier
        2. Development teams Project Realization
    5. We gaan zoveel mogelijk implementeren, maar gezien de beperkte tijd kiezen we ervoor de opdracht op te splitsen in kleinere zelfstandig uit te voeren opdrachten die we kunnen afwerken zonder dat daarom het geheel afgewerkt moet zijn.

JI
2021-05-03 15:01:29